An Internet Protocol (IP) specifies the format of packets, also called datagrams, that are to be broadcast and the addressing scheme. The transmission of a single (the same) message to a select group of recipients is called a multicast. Transmission of the message to only one recipient is called a unicast transmission. A system and method currently exists for enabling UDP (User Datagram Protocol) unicast transmissions over IP multicast networks. UDP is a connectionless protocol which is part of the TCP/IP protocol suite. TCP/IP is the Transmission Control Protocol that enables two hosts to establish a connection and exchange streams of data. Unlike TCP/IP, UDP/IP provides very few error recovery services, offering instead a direct/fast way to send and receive datagrams over an IP network. It is used primarily for broadcasting messages over a network. A UDP unicast transmission is considered to be a communication session involving two hosts, a client and a server. In a typical scenario, the client contacts the server requesting the transmission of the content of a file. The content can be any type of data in any form, such as desired files, or streaming data such as audio and video. As a response, the server sends the content in form of a stream of UDP datagrams to the client. A UDP datagram consists of a UDP+IP header and data.
The client is responsible for maintaining the session alive by periodically sending an appropriate message to the server, such as a “heart beat”, or repetitive, type signal that reiterates the client's continued interest in receiving the transmission and confirms the client availability to receive content from the server.
FIG. 1 illustrates how the existing technology works. This shows a classical configuration with a Server host 100 communicating with a Client host 120 over an IP network 110. The network 110 is typically the Internet, an Intranet or any other network supporting the TCP/IP protocol suite. As shown in FIG. 2, the Server host 100 is hosting a Server Process 220 for communicating with a Client Process 230 hosted on the Client host 120 following an application protocol based on UDP. The term Process means a conventional application program, or task, that here is executed by each of the Server and Client. The client process is the program (or the player) responsible as well for data consuming or displaying as for maintaining alive the communication session with the server. the server process is the program responsible to manage and distribute the requested data. All of this is conventional in the art. For example, the application protocol, or Process, typically can be a streaming protocol or any other real time protocol that implements a message flow. Examples of such a protocol are Microsoft Media Server protocol (MMS), RSTP as used by Real Networks, Xing Technologies XDMA protocol or RTP real time data protocol delivering real time information of any type.
As seen in FIG. 2, starting from the top and moving downward, in a typical scenario the message content flow is initiated by the Client 120 sending a request message REQ to the Server 100 indicating the desire to receive specific content and, for that purpose, specifying the IP address of the Client host 120 and the local port on which data is expected to be received. This message has the effect of establishing a session at application level between the Server Process 220 and Client Process 230. The Server Process 220 accepts the request by sending the desired content in a series of DATA messages to the Client Process 230.
In order to maintain the session alive, the Client Process 230 periodically sends a “heart beat” message signal HB to the Server Process 220 for the purpose of reassuring the Server about its availability and interest in to continue to receive the specific content. The time interval between two successive heart beat messages depends on the specific client-server application protocol. The Server Process 220 is configured such that if it does not receive a HB message in the expected time frame, it will stop sending DATA messages to the Client Process 230, thereby terminating the communication session.
Once all of the content has been completely transferred, i.e., the last DATA message has been sent from the Server to the Client, the Server Process 220 may send a CLOSE message to the Client Process 230, this for actively indicating that the session is terminated. Alternatively, the Client Process 230, in the absence of receiving DATA messages within a given time frame, will imply that either the transmission is complete or the connection to the Server Process 220 has been lost. Similarly, a Client wishing to interrupt the session instructs the Client Process 230 to send an ABORT message to the Server Process 220 or can simply stop sending HB messages.
FIG. 3 illustrates a typical scenario of how components on the Server 100 and Client 120 communicate. The Server Process 220 has a unique name associated with it which translates into a corresponding network-wide address. The translation procedure is carried out by a process known as the “domain name server” (DNS) on request of the Client Process 230. The resulting network-wide address of the Server Process 220 consists of two parts: the network-wide IP address of the Server host 100 and a local port number locally associated to the Server Process 220.
The operation of translating a domain name into a network-wide IP address is necessary only if the Server host 100 is known by domain name and not by IP address. Once the Client Process 230 knows the network-wide address of the Server Process 220, it is ready to initiate the communication. For that purpose, the Client Process 230 sends a message REQ to the Server Process 220 according to the protocol described above. An REQ message is typically sent by the Client 110 over a reliable transport control protocol 240, e.g., TCP, in order to increase the probability of successfully establishing a communication session with the Server 100.
Whenever a system has been designed to operate under less stringent requirements, the Client Process 230 can send the same REQ message over a transport protocol such as UDP, which is less reliable than, for example, TCP/IP, i.e., no data packet checking and/or redundancy. The user datagram protocol offers only a minimal transport service without guarantee of datagram delivery. It gives applications direct access to the datagram service of the IP layer. UDP is used by applications that do not require the level of service of TCP or that wish to use communications services (e.g., multicast or broadcast delivery) not available from TCP. UDP is almost a null protocol. The only service it provides over IP are checksumming of data and multiplexing by port number. Therefore, an application program running over UDP must deal directly with end-to-end communication problems that a connection-oriented protocol would have handled, e.g., retransmission for reliable delivery, packetization and reassembly, flow control, congestion avoidance, etc., when these are required. The fairly complex conventionally accomplished coupling between IP and TCP will be mirrored in the coupling between UDP and many applications using UDP. By default, a streaming program use, UDP to send data, TCP/IP or HTTP being too slow for it. A streaming application can allow a small data loss; this would not be even noticed from an end-user. Therefore, it is correct that UDP can be used when less stringent requirements.
The heart beat messages can be sent using a more reliable transport protocol since, as described above, HB messages are vital to the existence of the communication session. Alternatively, and depending on the Server Process tolerance, HB messages also may be sent over the unreliable type transport protocol. FIG. 3 does not show how CLOSE and ABORT messages are exchanged. These message types are preferably sent using a reliable transport protocol.
It should be noted how the described message flow requires the existence of a communication channel that allows the Client Host to communicate with the Server Host, a so called return channel. While this is a valid assumption for many wired networks, it may not be technically feasible or economically acceptable for satellite network or terrestrial broadcast networks. These types of networks typically implement only a forward communication path (Server to Client) and do not support a return channel that allows receiving devices to send information from the Client back to the Server. In order to support bidirectional services, service providers sometimes combine unidirectional wireless networks with wired network, for the purpose of complementing the existing forward link with the necessary return link. This approach increases the complexity and the costs of the implemented solution to a level that may discourage the service provider from adopting it.
The system shown in FIGS. 1-3 works well when only a few Clients are simultaneously requesting content from the same Server. Unfortunately, depending on the Server configuration, once the maximum number of connected Clients is reached, the quality of the service provided can degrade rapidly. This degradation is typically caused by at least one of the following reasons:
1. Server scalability: the Server is asked to generate multiple streams of content at the same time. Depending on the Server configuration and resources, the Server throughput may be limited to a quantity less than the effective throughput necessary to satisfy requests from a number of Clients.
2. Bandwidth consumption: the amount bandwidth B necessary to satisfy multiple parallel requests of content from the same Server increases as a linear function of the bandwidth b of one content transmission and the number N of requesting clients (B˜b*N). Depending on the network topology and resources available this amount of bandwidth required to satisfy multiple requests for content may exceed the overall bandwidth available for or allocated to this kind of transmission.
Moreover, the message flow described above requires the existence of a communication link from the Client to the Server, a so called return channel. While this requirement is typically satisfied in wired networks, existence of such a communication link may not be a valid assumption for unidirectional networks like satellite or terrestrial broadcast networks.
In the past, client-server applications that included unicast transmission capabilities, such as described above, had to be reengineered in order to take advantage of multicast or unidirectional networks. Various multicast capable applications designed around an open architecture exist on the market, such as Real System G2, Microsoft Windows Media, etc., but do not support unidirectional transmissions
The re-engineering task typically requires a more or less large investment of resources depending on the complexity of the application. It also increases the time required to place an existing application on the market. As a consequence, not all unicast applications have been modified to support multicast transmissions on unidirectional networks. Also, none of the above-listed systems can be used to enable an application designed around a unicast protocol to take advantage of a multicast environment without a re-engineering effort and its corresponding costs being applied to the application.